\documentclass[12pt,a4paper]{article}
\usepackage[english]{babel}

\newcommand{\super}[1]{\ensuremath{^{\textrm{#1}}}}
\newcommand{\sub}[1]{\ensuremath{_{\textrm{#1}}}}

\usepackage[top=2.0cm, bottom=2.0cm, left=2.0cm, right=2.0cm]{geometry}

\begin{document}

\title{\textbf{Don't settle for eventual: scalable causal consistency for wide-area storage with COPS - summary}}

\author{Si-Mohamed Lamraoui,
\and Ibrahim Safieddine}

\maketitle



\section{Introduction}
% ======================================================

	Modern web services use more and more distributed data stores. These data stores are most of the time designed to have a good availability and partition tolerance. As social services, such as Facebook or Google+, become much used these days, acceptable consistency is not an option for those ALPS systems. Unfortunatly, because of the CAP Theorem, we cannot achieved a strong consistency without degrading the performances of the system.\\
	Clusters of Order-Preserving Servers (COPS) introduces a new way to deal with wide-area storage without a demeaning of ALPS properties and consistency.


\section{System Design of COPS}
\subsection{The COPS Key-Value Store}
% ======================================================
	
	In COPS, each datacenter contains a cluster of nodes. These nodes keep track of \texttt{<key, value, dep>} entries. Each node is responsible of a range of keys. \\
	When a node received data from a client, it holds this data in a replication queue, then it will asynchronously send the data to the others datacenters. Before commiting these data, the datacenter will perform a \textit{replication checking} in order to verify all the dependencies within the cluster. Checking the dependencies allows the system to be causal consistency ordered for write operations and also prevents blocking for read operations.


\subsection{Client library}
% ======================================================

	The COPS client library allows a client to communicate with a local datacenter in a convenient way. The API offers a set of simple primitives (put, get, ...). The library manages operations in different manners if the client uses COPS or COPS-GT.


\subsection{Writing and Reading values in COPS and COPS-GT}
% ======================================================
	
\textbf{Writing to the local cluster:} When a client wants to write information, he sends a put(key, val, context\_id) message to the client library. The library computes the complete set of dependencies \textit{deps} and then calls put\_after without the version argument. In COPS, the library needs to include \textit{nearest}, and in COPS-GT the library includes \textit{deps} in the \textit{put\_after} call. The put\_after ensures that val is committed to each cluster only after all of the entries in its dependency list have been written.

$\linebreak$ 
\textbf{Writing replication between clusters:}  Once a write commits locally, it is time to replicate that write on the equivalent nodes in other clusters. Thus the primary node calls put\_after operation with the key’s version number. In COPS-GT the deps argument is included in the call. When a node receives a put\_after request, it issues a check dep\_check to the local nodes responsible for those dependencies to determine if the values nearest dependencies have already been satisfied locally. When a node receives a dep\_check, it immediately respond to the operation if the dependency value has already been written, and It blocks until the write is done if not.

$\linebreak$ 
\textbf{Reading Values:} To read a value, the clients call the get(key, context\_id) library function and then the library sends a read on the node responsible for the key in the local cluster. Since the deps are stored in COPS-GT, a client can request a specific version of the key using get\_by\_version(key, version).\\


\subsection{Get Transactions in COPS-GT}
% ======================================================

The COPS-GT client library provides a get\_trans interface to ensure causal+ consistency, by reading and writing all related keys in a transaction. To retrieve multiple values in a causal+ consistency manner, a client calls get\_trans with the desired set of keys. The COPS client library implements the get transactions algorithm in two rounds. In the first one, the library issues n concurrent get\_by\_version operation to the local cluster, one for each key of get\_trans. The second round happens only when the client must read newer versions than those retrieved in the first round.




\section{Evaluation}
% ======================================================

The evaluation shows that COPS completes operations in less than a millisecond, provides throughput similar to previous systems when using one server per cluster, and scales well as we increase the number of servers in each cluster. It also shows that COPS-GT provides similar latency, throughput, and scaling to COPS for common workloads.


\section{Conclusion}
% ======================================================

COPS respect the ALPS ans causal consistency. COPS-GT use transactions to ensure causal+ consistency and it also respect low latency.



\end{document}